1 comment
Hey All
Voxatron 0.2.13 builds are now up, and will shortly be up on Humble Store (check the version number in the filename). If you don't have a lexaloffle account (Games > My Games) and would like one, you can activate it from your humble store page (see this thread). To update from a Humble Store account, search your email for the download page link, or request a new one here.
The main two changes in 0.2.13 are much more flexible player control options, and moving to SDL2.
Player Controls
The default player control style is now analogue, which means that you can run and shoot in any direction! This will eventually be an optional property of players, but for now I decided it doesn't badly break the design of any existing cartridges so set it as default. This means the mouse control style can be more natural -- using ASDW + the cursor as an absolute point to shoot at.
Many users asked for this early on, but I stubbornly held out with a more minimal 8-way control set, wanting to keep the controls across games more simple, genre-agnostic, retro-feeling and unified. I was really, really wrong about that! -- it doesn't hurt to have analogue control in the vast majority of cases (even though existing carts weren't design for it), and it of course makes hardcore arena shooting much more fun.
It's also possible to assign buttons to various actions in the player designer, but more on that soon. (For a preview, check out the list of button actions in the player controls setup menu).
SDL2
SDL is the core library that Voxatron uses to do operating system-level things like window management and to talk to hardware (controllers, sound and video). SDL2 provides better controller configuration, multi-monitor support and doesn't crash on startup under recent versions of OSX (!) It also means I've had to change quite a lot of historically stable code, so there might be a few small glitches in this department for the next couple of updates.SDL2 has quite a nice controller configuration scheme, where many common controller layouts are automatically detected on startup and a best guess at the layout is made from a database supplied from other users (including a large number of Steam users). It's possible to add extra controllers or alternative mappings using the standard SDL2 layout syntax by adding a line sdl_controllers.txt (see vox.txt for details), rather than using the in-game config in earlier versions. This might cause some disruption for a few users, but should make controller setup much easier and more consistent in the long run.
** Linux users: The linux installer doesn't give you SDL2 automatically, so please either manually install SDL2 (http://www.libsdl.org) or wait for a follow-up update next week that will hopefully fix this.
Updated (but still very wip) manual:
https://lexaloffle.com/files/docs/voxatron_manual_213.html
Changes:
v0.2.13
Added: Analogue player movement and facing control
Added: Custom control mappings per player
Added: Inventory items assigned a useage button
Added: Transparent voxel rendering in Designer
Added: Cartridge metadata section with 2d 60x32 label
Added: Capture cartridge preview image in-game (F7)
Added: default_sounds flag for actors
Added: car-style control (turn left, right, accelerate)
Added: Low air friction flag in actor properties (on by default)
Changed: Moved to SDL2: better multiple monitor support, controller support and fixes OSX startup crash
Changed: Game controllers now customisable sdl's scheme (~/.lexaloffle/Voxatron/sdl_controllers.txt)
Changed: Control configuration format and default config values // camera is now O, P
Changed: Any actor now has low air friction after being thrown
Changed: Mouse control now uses absolute cursor position to determine player facing
Changed: Players have warp-in flag
Changed: Better 2d drawing for depth==1 props
Fixed: Duplicate object instance ids when dragging to draw multiple objects or stamping
Fixed: Internal pickup friction and mass
Fixed: Loading and saving a cartridge clobbers existing preview image
Fixed: Throwing using directional controls
Fixed: Import .xm file now fails gracefully for unsupported files (> 128k or > 8 channels)
Fixed: Jumping twice quickly causing annoying jump sound retrigger
Fixed: Actors not observing warp-in property at t=0
Fixed: Legacy default player starting position sometimes not at center of room
Hey All
Voxatron 0.2.12 builds are now up, and will shortly be up on Humble Store (check the version number in the filename). If you don't have a lexaloffle account (Games > My Games) and would like one, you can activate it from your humble store page (see this thread). To update from a Humble Store account, search your email for the download page link, or request a new one here.
Another update for folks designing stuff.. doors, Designer performance, .qb file importing, object instance browsing and title screen support. As usual earlier carts should still function roughly the same, but let me know if you notice any breakage. If there aren't any show-stopping bugs, I'm going to work on getting the manual up to date and posting some tutorials, but for now here's a quick intro to new features..
Doors
Doors have been simplified somewhat in 0.2.12. There is now a single property (length) that indicates how far you can walk into the pocket, and from which the old separate properties exit_depth, entry_depth and hide_depth are all inferred. It's also much easier to link 2-way doors, as you get a nice big 'Link' button every time a door is placed and there was a previously unlinked door selected. You can still manually edit the target_location.More door improvements: green-checkpointed rooms send the player back to a sensible position (even for door pickups that you jumped on top of), it's possible to stop the player loitering in doorways with the auto-trundle property, and it's possible to check if a door has a player standing inside it with actor:m-state:occupied (useful for doors that spit a player out and then self-close until the room is completed).
Object Instance Browser
I've added the first version of the room instance browser. It's not very useful so far, but can be handy for locating objects that are not visible and difficult to pick out of the timeline. I will gradually extend the browser to include filters (view only monsters / search etc), and to organise groups that can be locked/hidden and have their own timelines and activation conditions. This means we'll eventually get functionality similar to layers (that you might find in a painting program), a scene hierarchy, and multiple timelines.Optimisations
I discovered a ridiculous speed bottleneck that was slowing the Designer down for complex scenes, that I really should have checked earlier! You'll find that rooms with more than a few hundred objects will run much much smoother than before (typically 2x ~ 3x faster on my MacBook). I also found a similar bottleneck that was causing a bit of slowdown during gameplay when there were large, dense explosions..qb importing
The 'Load item into folder' button can now handle Qubicle Constructor (.qb) files. The colours are mapped onto Voxatron's palette, and all sub-objects are merged into a single prop.Title Screens
It's now possible to make proper title screens (no more hiding the player in a large box!). Instead of placing a player in the first room, place a SWITCH_ROOM script (you can find it in Internal > Scripts) with a trigger of SYSTEM:BUTTON:SHOOT. The script takes a single parameter which is the desired starting room number. Note that you only need to place the player object once in the first room you want them to appear. It's also possible to switch rooms, leaving the player behind until switching back again.v0.2.12
Added: Door linking button
Added: Object instance browser
Added: Internal scripts: DUMMY, SWITCH_ROOM
Added: Microscript event: system:button
Added: Microscript m-state: occupied (for doors)
Added: Door flag: auto-trundle
Added: Script instance property: execute once / times many
Added: Preserve relative position of player to door
Added: Qubicle constructor scene importer (.qb)
Added: Timeline instance thumbnails for custom objects
Added: Animation flag: animate only when host actor standing on ground
Added: Actor flag: collide_with_bullets
Removed: Immediate doors
Changed: Tweaked default object library, added tiny font
Changed: Simplified pocket doors. // exit / entry / hide depth are implicit
Changed: Loading screen rendered in voxel display
Changed: Green checkpoint saves player at door threshold
Changed: Room goals can only be cleared if player is still alive
Changed: Animate by actor movement takes "play speed" and observes dz
Optimised: Designer runs 2x~3x faster for complex scenes
Optimised: Emitting many particles
Fixed: Door entry depth
Fixed: Sometimes player actor set to last used door position when loading
Fixed: Wandering actors sometimes don't respond to collision events
Fixed: Dragon attack damage 0
Fixed: Actors that are not pushable or standable can not trigger collision events
Fixed: World animations not observing animate by movement mode
Fixed: Actors spawning into walls when using CLOSE / FAR / RANDOM spawn position
Fixed: Player re-spawning after cart is completed
Here's a WIP preview of labels designed for Voxatron 0.3.* releases. They will be mostly brushed up existing cartridges (e.g. Twisty Castle will be extended and given a 2P option), but there are a couple of news ones too. I'll let you guess what they are for now :)
Also just a heads up for designers, it looks like 0.2.12, which irons out doors, title screens, and many little engine details, will be ready at the end of this week.
Catch you soon!
- z
Hey All
Voxatron 0.2.11 builds are now up, and will shortly be up on Humble Store (check the version number in the filename). If you don't have a lexaloffle account (Games > My Games) and would like one, you can activate it from your humble store page (see this thread). To update from a Humble Store account, search your email for the download page link, or request a new one here.
v0.2.11 is mostly a bug-fixing update, but it does include one new type of object: fonts.
To use a font for drawing into a prop, make sure it is the only one selected as 'default font' (I'll make that easier later!), and then while editing the prop, open the console (escape) and type @Something. The text will be drawn in the currently selected colour.
Note that it's case sensitive, and the default font included only contains capital letters. To make your own font or extend the default one, just add the characters in any order and name them as themselves.
A couple of things I've bumped to 0.2.12 to get this update out earlier are the music importing bugs and also importing Qubicle .qb models. But next up is better documentation and some more tutorial carts!
Changes in v0.2.11:
Added: Fonts
Added: Collide events for particular sides
Fixed: Draw text command
Fixed: Shoot button triggered by movement button events
Fixed: Missing voxel cursor
Fixed: Actors can fall through thin pieces of floor
Fixed: Rotated non-square actors get stuck / climb walls
Fixed: +1 Life logic
Fixed: Sword base weapon starts as peagun for single shot
Fixed: Microscript DEF_ID, OBJ_ID selectors
Fixed: Paste into current item crashes
Fixed: Crash when saving world state
Fixed: Can draw boxes in title screen with mouse
Fixed: Freeze pickup destroys falling debris
Fixed: Bullet leaving debris incorrectly
Fixed: Crash for short rooms
Fixed: Invalid extend_walls value handled robustly
Fixed: LERP over 0 seconds crash
Fixed: help tip drawn over top of checkboxes
From 0.2.10, it's now possible to import .xm module files and embed them in your cartridges.
If you'd like to try making some .xm music, I highly recommend Milky Tracker.
To get started, here's an example .xm file (feel free to use it in your levels too):
https://www.lexaloffle.com/bbs/files/1/dirtbag_ingame.xm
To import:
In the objects tab, click the "Load Item Into Folder" button.
Navigate to the folder you stored the xm and double click it.
You should see the music item appear in the current folder.
To add music to a room:
Edit the room you want
Click once on the music item to select
It should now appear in the pull-down list "MUS"
Press SPACE to stop playing the music in the editor
Know issues:
The .xm player can't handle everything yet! Some of the effects/commands are missing, and it can only load 16-bit instrument samples.
Hey All
Voxatron 0.2.10 builds are now up, and will shortly be up on Humble Store (check the version number in the filename). If you don't have a lexaloffle account (Games > My Games) and would like one, you can activate it from your humble store page (see this thread). To update from a Humble Store account, search your email for the download page link, or request a new one here.
NOTE: 0.2.10 can not read old player history files. If you're in the middle of a long level, you might want to finish it before updating
0.2.10 contains many new engine features that will be of interest to users making carts: microscripting, persistent worlds, player and weapon editing, music importing, many new actor properties, nice doors. There's new stuff to play too! I've added a cartridge selection menu with a new arena (Chaos Arena) and some test carts to fool around in.
If you take a look at the editor, you'll see there are now some new default objects in the 2nd and 3rd tabs. These are all made from scratch in the editor, and can be used as templates to make new monsters (or just examples to learn from). The 4th and 5th tabs are still read-only internal objects that can be mixed with new stuff, but eventually I will try to remove all of the legacy items. In particular, there should no longer be any need to use the old door scheme.
There are surely many small glitches and details I still need to attend to, but it should be mostly stable and functioning. I'll be posting new tutorials over the next couple of weeks, but in the meantime have a look at the new example objects, and here's a half-finished user manual:
UPDATE:
How to add music: https://www.lexaloffle.com/bbs/?tid=1580
How to use doors: https://www.lexaloffle.com/bbs/?tid=1579
Changelog:
v0.2.10
Added: Custom players
Added: Chaos arena (alpha demo cart)
Added: Custom doors and spawn points
Added: Custom bullet properties and crater sizes
Added: World permanence system // elephant mode / collect_once
Added: Green checkpoint flags (save when exiting room)
Added: Room objectives / room clearing
Added: Extended microscripting and inter-room superstates
Added: Actor property value mini-functions
Added: Base types: shape, colour
Added: Modifiable room height (maximum 64)
Added: Room properties: liquid_z, extend_walls, skip_timeline
Added: Motion blur for fast moving actors
Added: Actor properties: friction, bounce, density, attack damage
Added: Actor facing quantization
Added: Cart selection for alpha demo levels
Added: Transparent colours
Added: Maximum player life pickups
Added: Save point pickups
Added: Default objects and templates
Added: Music importer (.xm)
Added: Audio triggers
Changed: Collision events can optionally apply to walls/actors/any
Changed: Microscripting statements replace old object instance triggers
Changed: Removed minimim 4x4x4 size limitation on props
Changed: New savegame storage (historic saves invalidated - sorry!)
Optimized: File saving and resulting png size
Optimized: Editor rendering, gui responsivity
Fixed: Floating ground caused by destructive weapons
Fixed: Team logic for bullet collisions
Fixed: Pasting objects from another file yields duplicate ids
Fixed: Sound mixer thread crashes
Fixed: BBS level title clobbering
Disclaimer: this feature is still in R&D, highly experimental and might not make it into the alpha anytime soon. But for your viewing pleasure, here's what Voxatron looks like with a volumetric light attached to the player. I really want a scene in the main story cart (1.0) that has the main character walking through a forest at night with a lantern, with snow catching the light as it falls into view. I tried making a quick mock-up using a brute-force method and it turned out to be fast enough to be interactive, but not yet useable.
Technical explanation:
This new lighting model is made possible by the way I'm calculating shadows. Instead of generating a traditional 2D shadow map, I instead generate a 3D 1-bit volume, where each set bit represents a fully lit voxel. The volume is then sampled while drawing voxels to give soft shadows. To do rough attenuation using 1-bit values, I dither the maximum light distance based on xyz (and t for flickery torch-style light), and then let the sampling take care of producing a smoother version. I still kind of like the 1-bit version though for large simple geometric shapes.
The beauty of this method is that the light volume can be generated in any fashion and still rendered at the same speed. It's possible, for example, to blit many blobs of light into the map (e.g. for bullets or explosion particles) with hardly any additional cost. To do light emitted from a point and casting shadows, I'm currently doing a line-of-sight march for every voxel. It was faster than I expected (I was only trying to generate some still frames to look at!), but I have a much more efficient method in mind for this, which I'll post about later if it works out (or not).
Here's an idea I'm playing with for 0.3..
One of the concepts I want to communicate is that the Voxatron Designer is for making whole games (or animations / shows / demos / playgrounds / music disks ), and not just Voxatron levels with a robot who goes around shooting monsters up. Also, I want to give people making carts the feeling that they've made something that has its own separate identity as a creation that can be shared. To do this, I'm playing with the idea of presenting Voxatron as a kind of virtual console (following more closely the pico-8 philosophy, which was supposed to be a mini 2d voxatron in the first place!).
This means that when you're browsing BBS levels, each one would be shown explicitly as a cartridge. The current BBS levels browser already kind of hints at this, but I think it could be interesting to go the whole hog:
Each cartridge has a 60x32 image that can optionally be drawn by the cart's designer, along with a choice of cartridge colour. I'd have to figure out a nice way of showing the titles on the top for easier browsing.
What do you think? Do you like the current minimal menus, or would you like to see Voxatron as a clunky pseudo-retro machine?
0.3 is a special number to me; it's the version of Voxatron that I internally take to mean 'Voxatron is now also a platform'. The aim of 0.3 is to round off a complimentary set of tools and engine features for making levels and whole games that don't resemble Voxatron beyond utilizing Voxatron's virtual display format. The machinery to do this covers around half of the project. Crafty users have already made some wonderfully surprising levels, but I think the difference will be 'How shall I make this in Voxatron?' rather than 'What could I make in Voxatron?'.
With 0.2.10 taking shape, and destined to serve as a kind of beta for alpha 0.3 (does that make sense?) I thought it might be a good time to give you a look slightly further into the future. And also wave my hands around one more time before you can actually try 0.3 firsthand and try to convince fleeting blog-readers how cool it will be.
v0.3 Features
This trailer demonstrates some of the upcoming features using no special hackery for the park scene. The leaves are emitted monsters that wander while they're not standing, the duck leans against the top-hat guy when close using an object-specific trigger, the hud is turned off, and solid animations are used to allow the girl to be animated but still able to be walked over with per-voxel collisions.
The following features are already working in my dev builds, and will appear in 0.3. For the next month or two, I'll be carefully attending to details; freezing the design of each behaviour so that I don't break backwards compatibility, debugging, writing user manual entries, and resolving any left-over design confusion (my confusion, that is) about how exactly features should work. I've learnt from doing quick design to release cycles that this can yield a long tail of around 10x as much maintenance in bug-fixes and work-arounds once they are live (blue doors, or NOITEM triggers, anyone?), so in that respect I fear I'm sitting on a potential wagon of long-fuse dynamite.
To alleviate this, I will be rolling out features as gradually as I can in the remaining 0.2. updates, but it might be a bumpy ride. I should take this chance to quickly thank everyone in advance and who has already been posting levels for being so tolerant while I flounder around fixing and re-breaking their levels. Making something like the Voxatron editor has been a personal dream of mine, and I can't understate how vital tenacious and creative users have been to help make it happen. You guys rock. sniff*
Right. So, the core 0.3 features are:
1. Microscripting: Activation controllers can query any actor or group of actors in the world, and perform logical expressions over them as a collection (e.g. If any actor in group x has a distance closer than y to this actor..). Expressions can also query the state of objects in other rooms -- for example, you can check to see if a boss monster has been killed in one room to trigger opening a door in another room.
2. World Persistence: Rooms can optionally be recorded/saved in exactly the way they were left including wall damage and actor position and states. Otherwise, it is possible to turn existence persistence on per-object, so that a monster only spawns once or a pickup is only collected once.
3. Doors: Doors are defined in a way similar to actors, with their own animations (that can be solid) and triggerable modifiers. You can, for example, make a door that has an opening animation if a player is weilding a key close to it. Doors also have off-screen pockets of empty space for much nicer room transitions. Finally, they can be used to spawn players after the room has started, or to remove them from play -- useful for making story screens and showing action before the player arrives on the scene.
4. Custom Audio: Music can be imported and saved with the level file (.xm tracker modules), and sounds can be triggered by activation controllers. I'll make a synth designer later, but in 0.3 there will be a standard library of sounds to choose from.
5. Player Inventories: Pickups can optionally include an INVENTORY_ITEM definition that controls how players can collect and store them, how much ammo they have, how they are displayed, and how they interact with other pickups. For example, it's possible to rig arcade-style weapons or to make an rpg-style inventory where the player can select between collected items and wield them at will.
6. More Physics: 0.3 will handle actors' physical properties better, including their weight on collisions, how bouncy they are, and with definable friction. This is the last time I'll change the core physics, but in any case older levels should still work roughly the same (unless you have the player hoisting incredibly large objects).
7. Custom Players: players can be defined in a way similar to monsters. Old arcade pickups can still be used with special legacy options, or you can define custom attacks from scratch as part of the definition (triggered by inventory items).
8. Multiplayer!: Multiple active players can be present in the same room, and enter neighbouring rooms either when one players goes through a door, or when all players are close to or inside a door. Using a team grouping system, players can either hurt each other, be pushed around by each other's bullets, or not interact at all.
Wishlist
There are a bunch of things that would be nice for 0.3, but it's important to keep it as focused as possible. For example, there should eventually be tools for managing room objects, for generating bits of the world procedurally to make rogue-like-likes, or for making speech bubbles easily. These are all things that can be rolled out separately in later updates without impacting the design of core features.
However! If anyone's working on a level that really needs a particular little engine design tweak, feel free to suggest them for consideration. I can't promise anything for 0.3, but might be able to do them in a 0.3.* update or adjust the existing features to handle a work-around.
Release Plans
I don't have a date fixed for 0.3 yet, but anyone keen to sink their teeth into the new design tools will be able to access most of the features in 0.2.10 (the next update, coming soonish..). I'm hoping (nudge nudge*) to give users a chance to design some more stuff before 0.3 so that it's already available for the launch. Of course, I'll also be making a new demo level of my own with the hope that some players will come for the game, but then stay for the engine and tools.
You may have noticed that the BBS has been somewhat quiet, which has a few upsides (it's very tricky to support a constant stream of legacy levels!), but of course it would be great to address this, and 0.3 will be a good point to start investing more time into promoting the game and community. In fact, this was one motivation for making the trailer above -- I've set up a good toolchain for making silly trailers to keep players and potential players in the loop. Along the same lines, I'll also get the basic community tools finished before 0.3 (level ratings, playlists, competitive scores).
Ah.. what about the game?
Some of you might be here for the Robotron arcade mode or adventure mode, and wonder why I'm always going on about the engine and tools. I have been continuing work on the main story, but I'm not ready to reveal much about it until closer to 1.0. New arcade modes will be available much sooner than that however, with a new arena also coming in 0.3, and later 0.5 will be focused on developing the arcade experience (0.4 is for scripting).
That's all for now -- please feel free to offer any thoughts on 0.3 development direction or what you'd like to see happen with the release and I'll catch you on the flipside.
Hey all
I'm currently working on Voxatron 0.2.10 which will serve as a kind of beta for v0.3, introducing custom players and various supporting functionality. This will bring the engine quite close to being feature-complete minus lua scripting. I've been mainly occupied by engine / voxde stuff for around 2 years now, so this is a very exciting prospect!
I was hoping to do a more intermediate update, but it looks like this is going to be an all or nothing situation and I've decided to make the jump and cram everything needed in there. So while I get this together, let me give you a quick preview in case it changes your approach to any work-in-progress levels.
Custom Players and Weapons
Apart from finally being able to define custom-sized players, you'll also be able to add emitters, animations and modifier control similar to monster definitions. Modifiers can be activated by legacy conditions (shooting-left) or by buttons (host.button.shoot). To support this, there will also be some provisional way to collect pickups in an inventory that can activate modifiers that express the pickup. For example, collecting a 'blobgun' pickup might auto-wield and replace a 'fireaxe' because they are in the same wield-group, making it an arcade-style pickup. (Later it will be possible to collect multiple weapons and choose between then rpg-style).
Custom Doors
Instead of placing separate door items and props, doors will be definable as a single package of components similar to monster definitions. The components can also be triggered by modifiers as usual. For example, a door might open automatically when a player is close, activating a different door animation and mode of interaction. They also have custom hitbox attributes the same way as regular actors, so it's possible to make a very long invisible door that covers a wide exit area.
An extra non-vital feature I quite like is that it's also possible to define door 'depth' -- the size of a pocket of abstract space the player disappears into before entering the next room. This will be useful later for multiplayer levels where all players must enter the pocket to enter the neighbouring room.
State Saving
Custom players and doors add extra data that must be saved to disk, so it's also a good time to finish of the world permanence system. 0.2.10 will allow 2 ways to save room states: either the whole room is in 'elephant mode', where every detail is remembered (including holes in walls and monster health and positions etc), or each separate object can be marked as 'die once' and/or 'collect once'. In combination with the new doors, it should be possible to replace all of the bollocks 'blue door', and 'use once' malarkey from earlier versions.
Audio Triggers
The last piece of functionality that I think is holding monsters back is the ability to customize sound for their behaviours. I won't attempt to add a whole synth designer in this update (that will come later), but I've added the ability to at least select sounds from the built-in library and trigger them (or music) along with a modifier.
Custom HUD
This isn't really vital to get 0.2.10 going, but it's nice to be able to change or turn the inventory off. Especially if you'd like to do a story scene or an adventure-based level where the focus is on exploration and item discovery rather than scores or weapons.
日本語 fullpowersideattack.com ブログ投稿!
If you're at the Tokyo Game Show this weekend, please swing by the Indie Games Area (Booth 9-C7) and pay us a visit! Lexaloffle is teaming up with FullPowerSideAttack.com to run a booth on Saturday the 21st and Sunday the 22nd of September. I'll be there on the Sunday to show Voxatron (of course) if you want to say hi, and nanmo-san from FPSA will be there both days demoing the adorable physics platformer, TorqueL.
Hey All
Voxatron 0.2.9 builds are now up, and will shortly be up on Humble Store (check the version number in the filename). If you don't have a lexaloffle account (Games > My Games) and would like one, see this thread. To update from a Humble Store account, search your email for the download page link, or request a new one here.
v0.2.9 is an incremental updates that includes fixes to keep the BBS levels (mostly) functioning in the wake of underlying engine changes, some improvements to activations controllers, and a couple of new base types for fun (jelly, mud).
I've removed the experimental player editor for now, but it will come back in 0.2.10 in its completed form, at which time we can finally ditch the "_char" hack (Woo!)
This is also the last build that the existing doors and save game system will appear -- I'm aiming to have proper custom doors and full world state saving finished in 0.2.10 to go with the new player editor.
Some quick notes about activation control:
- you can now optionally type a 5 character (or less) string in the group field instead of a number.
- you can choose if the component is reset each time it is activated, or continues -- e.g. if you want an animation or emitter to continue from the same state it was last at.
- shift-P to play in debug mode, you can use '[' and ']' to look at monster's state
Solid animations are designed to be used for doors in 0.2.10, but might be useful. Set the solid option on a stand-alone animation, and it will be drawn into the game world as a physical, floating object. This means the animation should not be moving or change orientation, or you'll get weird results. It can be animated though, of course! This is done by subtracting the frame from the world, and then drawing the next one in.
Changes in 0.2.9:
Added: Solid animation mode
Added: Mud, jelly base types
Added: Activation control optional reset
Added: Activation control group can be a 5-char string
Added: Monster debug information (shift-p to play)
Changed: Reverted to 0.2.7 soft shadows
Changed: "Edit Item" button also opens containing folder
Changed: Backups are now single copy rather than appended
Optimized: Custom bullets
Fixed: Emitter going crazy in Journey to the East boss
Fixed: Bullets with duration 0 not expiring on collision
Fixed: Start position when entering from voxde
Fixed: Start position when spawn point is inside wall
Fixed: Collisions for long skinny actors
Fixed: Camera controls not responding while player is dead
Hey All
Voxatron 0.2.8 builds are now up, and will shortly be up on Humble Store (check the version number in the filename). If you don't have a lexaloffle account (Games > My Games) and would like one, see this thread. To update from a Humble Store account, search your email for the download page link, or request a new one here.
0.2.8 is mostly another bug fixing update. If you've been away for a while, check the 0.2.6 update post to learn more about recent features.
This update includes water displacement, and a bunch of fixes for monster editing functionality. Here's the water in action:
I've updated the monster editing tutorial to reflect changes in 0.2.8. The only tricky difference is that instead of using labels to group animations (e.g. 'body'), they now follow exactly the same rules as modifiers. That is, each item has a standard activation controller. This can be useful for doing things like starting an emitter shortly after its containing modifier has been activated (e.g. trigger: parent, t == 240). You can also use it to daisy chain animations together without needing to wrap them in modifiers, using the activation controller's NEXT attribute.
Changes in 0.2.8:
Added: Animations and emitters have their own activation controllers
Added: Trigger by parent time or activation
Added: Water displacement
Added: Facing and heading control
Added: 2x1 antialiasing
Changed: Soft shadows are softer
Improved: Slowdown for many monsters / particles
Improved: Water physics & stability
Improved: Memory leaks
Fixed: Custom monster scoring
Fixed: Wall climbing
Fixed: Head stuck in ceiling
Fixed: Collisions for tiny objects
Fixed: References of pasted compound objects
Fixed: First emit at t=0
Fixed: Blue door sometimes not spawning
Fixed: Crash caused by rotated solid-mode animations
Fixed: Overflowing tab labels
Fixed: Patrolling platforms broken in older levels
..that doesn't sound right.
Polygon.com came to visit earlier this year to talk about Voxatron and Lexaloffle's newly evolved cafe-form. It's more of a personal story than about development (it was originally for their "Human Angle" series) but I think does a nice job of introducing the direction of the project that I haven't really talked about much yet outside of BBS comments. That is, treating Voxatron not just as a game but also as a platform for creating programs that can run on Voxatron's display.
[edit: updated to reflect fixes in 0.2.8]
This tutorial will show you how to make a zoib from scratch -- a simple monster that chases the player and occasionally shoots out some bullet patterns.
You can see some slightly more complex versions in action here:
Introduction
Monsters in Voxatron are represented as special folders that contain the monster's parts, along with a set of attributes given to the monster. Other objects are represented in a similar way -- for example, an animation is essentially a folder of frames. The monster's folder can include any combination of animations, modifiers, emitters, and anything the monster might emit: bullets, pickups, and even other monsters.
The components we need to make a zoib are:
- The monster's basic structure
- Monster properties
- Some animations to display the monster
- Some modifiers for the behaviours
- A bullet definition
- An emitter that sends out bullets during the attack
1. Create a minimal monster
Start by creating a monster item and putting an animation inside it.
- Create a new item somewhere in the Objects tab and set the type to monster.
- Double click on the monster folder to look inside (it will be empty to start with)
- Create an animation: new item, set type to animation
- Double click on the animation to look inside (again, empty to start with)
- Add one or more props as frames and draw a test squiggle to get started.
Congratulations! You have a working monster! You can now click the back to room button (bottom left) and place the monster and hit P to play. It will sit there motionless (because the default movement is 'none'), but will hurt if you touch it.
The structure of the monster now looks like this:
Monster
Animation
Prop frame0
Prop frame1
..
|
If you've made monsters with earlier version, you might have noticed that the 'set marker' button is missing. The marker -- the model shown in the editor when place an instance of an object -- is now automatically taken to be the first prop found in that object's folder.
2. Give the Monster some Properties
Go back to the monster definition using the item navigator. Note that you can click the breadcrumbs at the top of the navigator once to open that folder, or twice to also jump to that item's definition.
Monsters currently have the following properties:
Width, length and height are in voxels. This defines the collision box and can be completely different from the animation size. Make sure the size of the monster roughly matches its appearance. It also helps to give the width of the animation and the width of the monster the same parity (i.e. both odd or both even).
Gravity: 1.0 is roughly the same as the robot.
Life: Number of hitpoints.
Mortality: Any damage inflicted on the monster is multiplied by this value. i.e. 1.0 means normal damage, 0.5 means 50% damage, and 0.0 means the monster is immortal.
Density: Determines the monster's weight / floating level in water. * not yet implemented! Just leave at 1.0
Points: Points scored when the monster is killed. * fixed in 0.2.8!
Team: Which team the monster is on. Any bullets emitted from the monster will inherit this team value, determining which other actors it can hurt. 0 means no team and will hurt any other actor.
Lock X, Y, Z: Lock the position (X,Y) or elevation (Z) of the monster.
Speed, Jump Height: 1.0 is roughly the same as the robot. You probably want to turn speed down for most monsters.
Jump Freq: How many frames on average between jumps. The world is calculated at 120 frames per second, so a value of 240 means jump about once every 2 seconds. 0 means never, 1 means constantly bouncing.
Turn Speed: How fast the monster can turn in rps; i.e. 1.0 means one full rotation in one second.
Move Style: How the monster turns and moves:
> None: Do nothing.
> Wander: Randomly wander around without reacting to the player's location.
> Chase Player: Turn towards the target (player) and accelerate towards them. The stop to turn parameter means that the monster will only accelerate when facing roughly in the desired direction. Leaving it unchecked results in a more loopy movement path. If X-Ray Vision is not checked, the monster will revert to a wandering behaviour after losing sight of the player for several seconds.
> Patrol: Walk straight until hitting something, and then turn by the specified angle. Angles are in full rotations, so 0.5 means turn 180 degrees.
Interaction: Usually you want to check the first 3, so that the object has collidable sides and can be stood on. Check hoistable & throwable if you want to be able to pick up an object (by pressing shoot infront of it) and throw it (by pressing shoot while carrying).
Eat Walls: If the monster hits wall, bite a chunk out of it about once per second.
Atomize, Leave Debris: Explode into separate voxels on death, that optionally settle on the ground.
Spread out: Avoid walking too close to other monsters. If this is unchecked, monsters tend to bunch up into tight packs (like the demo pig)
Count as Monster: Used in conjunction with the NOMON trigger. e.g. if you're making a crate that doesn't need to be killed in order to trigger a door, you would leave this unchecked.
Hurt Player on Contact: Choose if the player is hurt when standing on top of and/or touches the side of a monster.
Facing Control: The direction in which the monster is accelerating (heading) and the direction that the monster is visibly rotated (facing) are two separate values. This means that you can have for example, a monster that patrols left and right, but is always facing the player.
> None: Remain facing the direction that the actor was placed
> Face player: Always turn to face the player
> Face dir: Turn to match the heading
> Turn: Turn a given amount each frame
Facing Control's turn speed is also given in rotations per second.
3. Give the Monster some Animations
Navigate back to the monster's animation and add some more frames. It's possible to add as many separate animations as desired, but for this tutorial we'll use a single walking animation.
By default, animations will just loop, which is not what we want for a walk cycle; if the monster is stationary, the frame number should not advance. To fix this, navigate to the animation properties and set Play Style to Actor Movement. Also, you'll need to check 'Rotate with Actor'.
I've also given the animation a name: body. You can call any object anything you like, but only one animation with the same name can play at any given time. (** this will change -- see notes on this below in the modifiers section).
The other properties are as follows:
Duration: controls how many world ticks the animation is dislayed for in world ticks. 120 == 1 second. Only relevant for looped / play once and hold animations.
Frame Length: controls how many world ticks each frame is shown for in world ticks. Again in world ticks, so using 8 means that the animation is displayed at 15 frames per second (120 / 8).
Anchor: The anchor controls where the animation is drawn with respect to its xyz coordinates in the world. Monsters' coordinates are taken to be bottom center, and so you normally want to also use this for monsters' animations. Bullets are taken to be at the center of the collision box, in which case animations should also be centered (center center).
Offset: Further positioning with respect to the anchor. These values are in the same coordinate space as the editor -- so if you draw a character facing the camera, then using X = 5 will shift the animation 5 voxels to the right (the character's left), and Y = 5 will shift it infront (towards the camera). Checking 'Rotate With Actor' will cause X & Y to be rotated according to the host actor's current facing angle.
Play Style: Controls how to advance through the frames. The only tricky one is 'Actor Movement' -- this causes the frame to advance when the actor moves one voxel in any direction. So if you draw a walk cycle with feet that move one voxel at a time, they should roughly line up with the ground (avoiding a moonwalking effect).
Paint Mode: Paint Solid only draws voxels on existing world voxels; Paint Empty only draws voxels in empty space (never clobbering existing voxels).
Draw in Screen Space: Ignores the camera position (useful for titles, scrolly tricks), and Random Starting Frame
The rest of the properties: Hitbox size, Gravity, Locking and Interaction are ignored for animations that are part of a monster. They are used for animations indpendently spawned into the world and have the same meaning as the corresponding monster properties. (i.e. they become physical objects similar to monsters).
4. Modifiers
Modifiers are alternative monster definitions that are triggered given some condition. For example, when the monster is shooting, you might like to change the animation and speed of the monster. Modifiers can replace part or all of the monster's definition.
Let's make a modifier for the zoib that causes him to shoot. This is a bit complicated, because we also need a bullet definition, an emitter to throw out the bullet, and a new attacking animation. These 3 things will be contained in the modifier's folder. For now we can test out the modifier without these 3 components:
In the monster's main folder, create a new item and give it the type 'Monster'. This time, check the modifier option.
You'll notice that the definition turns grey, and contains the values that we set for the parent definition earlier. By clicking the little triangles, it is possible to specify which values should be modified when the modifier is active, and which values should be taken as-is from the parent.
There are two things we can set now:
- The monster's speed should be zero while attacking, so click on Speed and change it to zero.
- To control when the modifer is active, set the event to Event:Random(480) and Duration to 120. This will cause the zoib to randomly attack every 4 seconds on average, and remain in attacking stance for 1 second (these values are in world ticks at 120fps).
Test out the monster by placing the monster in the room (if you haven't already) and hit P to play. The monster should chase the player, but then stop moving for a second every now and then.
The modifier activation settings are as follows:
Duration: How long the modifier remains active for in world ticks. 0 means forever.
Next: Which modifier to activate when this one expires (0 for none)
Priority and Group: If group number is set, then only one modifier in each group can be active, selected by highest priority.
Delay: How long to wait before the modifier can be activated again (taken from time of expirey, not activation).
Trigger: Alloes the modifier to activate itself given a specified condition.
Triggers:
Collide: collide with another object (you need to set the which_side parameter pull-down)
Hurt: when host actor is hit
Position: when the host actor is in the air, on the ground, or swimming
Speed: when the host actor has a speed in xy of some value
Life: of host actor
Time: host actor's world ticks ( 120 == 1 second old)
Random: every n world ticks on average
Periodic: every n world ticks
Changing animation when a modifier is active:
Animations follow the same activation rules as modifiers -- only one animation of the same group can be active at a given time. To create an attacking animation that is shown while the modifier is active, create an animation inside the modifier folder and give it the same group number as your walking animation.
I've made a 3 frame looping attack animation for the zoib:
After you've added the animation, hit P to play again, and check that the animation changes when the monster stops moving. If you get overlapping animations (i.e. both the walking and attack animations are drawn over each other), make sure they have exactly the same name.
5. Bullets
Next up, we need to create a bullet for the monster to shoot out. This will be an entirely self-contained object that could be spawned by other monsters or emitters, and could be stored anywhere in the navigator. But for convenience, it's nice to store it inside the monster's attack modifier.
The steps for creating a bullet are very similar to creating the initial monster. Navigate to the attack modifier's folder and create a new object (next to the attacking animation). Set type to bullet, open the bullet's folder, make an animation, and draw some frames. The result looks like this:
Note: leave the bullet's animation's anchor to the default of 'center center'. This means that you need to draw the bullet hovering in the center of each frame, rather than on the ground as with monsters. You can test that bullets animations line up with their collision hitboxes by checking to see where they leave holes in the walls. If the hole seems to be too high or too low, either the animation is not centered, or the anchor is wrong.
The properties of the animation are similar to before, except that I've used 'Loop' in stead of 'Actor Movement'. Because the animation is hosted by the bullet, the physical properties of the animation (size, gravity, interaction, locking) are ignored. [In future versions the interface will let you know about this automatically.]
Now to the bullet's definition:
Width, Length and Height define the size of the bullet's hitbox. For small bullets I usually just leave this to 0,0,0 -- which means the point at the center of the bullet needs to be inside another actor's hitbox for it to collide.
Gravity: 1.0 means the same as the robot. 0.0 means travel flat.
Duration: How long the bullet should stay alive, or zero for forever. Try 480 (4 seconds) for a fast bullet. You should set some value less than 1200 for this to avoid slow bullets accumulating to a very large number, unless you're very certain the bullet will die at some point. If you're using a positive gravity value and no duration, make sure Collide With Ground is set.
Collide With/ Hurt Same Team: The team index is taken from the host actor that emitted it. A team value of 0 means no team, and never counts as the same team.
Lock: lock position on each axis.
6. Emitters
Emitters are used to spawn any kind of object (including other emitters) into the world. They can be stand-alone independent world objects (in the way that animations can be), but can also be contained in monsters/modifiers to implement attacks.
There's no way to test out the bullet without an emitter, so let's make one quickly just to see the bullet working:
- Inside the attack modifier's folder, make a new item (the 3rd, next to the bullet and animation), and set type to Emitter.
- Before editing the emitter, find out the id number of the bullet by clicking to edit it, and look for 'Editing Bullet id:x' at the top right.
- Now edit the emitter, and set 'Source ID' to that number.
- Set Bursts to 1, Z to -4, and Delay to 0
Run that, and you should see the monster dropping a stationary hovering bullet each time he goes into the attack modifier.
Let's try a triple shot:
- Change Pattern to Spread.
- Num: 3, Magntitue: 0.5, Angle: 0, Rotate with Actor: On, Spread: 0.25
The properties of an emitter are follows:
Source ID: The thing you want to emit. Find out the id by editing it in a different tab (will add an easier way in the future).
Bursts: How many bursts to emit. 0 for continuous.
Burst Frequency: How many world ticks inbetween each burst (by time), or how many voxels the host actor need to travel for one burst (by movement). The first burst is emitted at the moment the modifier is activated (* fixed in 0.2.8)
Spawn Position: Where to spawn relative to the emitter (or host actor's) position. Same meanings as animation offsets; Y = 10 will position the spawned object 10 voxels infront of the emitter/actor.
Velocity: Same again, but for velocity of the burst. This is added to any other velocities generated by the pattern (e.g. so you can have a ring that is expanding, but the whole ring is also moving)
Pattern Single: Emit a single item.
Ring: Emit a circle of items moving apart at speed of 'Magnitude', offset by Angle, and increasing the offset by DAngle each burst (to create spirals).
Spread: Emit an arc of items. Similar to ring, except spread controls how much of the ring to cover. 0.25 means a quarter-circle.
It is currently possible to emit monsters, animations, bullets and other emitters. Don't try to emit the emitting emitter, because you will make Voxatron cry.
Notes
Emitters currently follow the same activation rules as animations; they are active when their parent folder (e.g. modifier) is active. This will probably also change in the future along with animations to allow emitters to activate themselves without the need to be contained inside an additional modifier.
If you can't figure out why something is not emitting or visible, try running the level in debug mode: press left_shift-P to play and you'll be able to see how many objects of each type are active. Also check that you're not emitting staight into the ground (try a large negative Z offset value like -10) and that the object has an animation, and that the modifier is actually triggering (try trigger self.t == 120).
If you want to try modifying the zoib to make multiple attacks, just duplicate the modifier folder (click to select, Control-C (copy), ENTER to deselect, Control-P (paste)), and then change the parameters of the emitter (and possibly the animation and bullet definition).
The zoibs in 'Zoib Arena' are slightly more complex -- they contain an extra modifier leading up to an attack, so that the player has a chance to get out of the way. They use the 'Next' parameter in the modifier activation settings to daisy chain the two modifiers together. This is why the attack modifier has no trigger itself.
That's all for now! Let me know if you have any trouble, or if there are points that need clarifying.
Here's the resulting test zoib file that results from following this tutorial. Feel free to use it as a template for your own monsters:
Here's a test arena for some more custom monsters. There are 3 types of Zoibs, and 3 shooting patterns.
Unfortunately the scoring is currently broken for custom monsters, so you can only play for completion. When you see the sushi, you're around half way there. Tip: don't use the pickups until you really need them.
Have fun! Let me know if you can beat it.
(note: you need version 0.2.6 or later to play this level)
Voxatron 0.2.7 builds are now up, and will shortly be up on Humble Store (check the version number in the filename). If you don't have a lexaloffle account (Games > My Games) and would like one, see this thread. To update from a Humble Store account, search your email for the download page link, or request a new one here.
This is a quick bug-fixing update. For more information about recent features, see the 0.2.6 update post.
This version should allow all of the existing BBS levels to playable roughly as they were. Please let me know if you see something that looks broken that didn't used to be.
Changes in v0.2.7
Added: Object counts shown in debug mode (shift-P to play)
Added: Clamp camera to room edges button
Fixed: Facing control not shown in monster properties
Fixed: Lava cold-start
Fixed: Emitted bullets not inheriting team value
Fixed: Size field shown for non-props
Fixed: Multi-spawned monsters stuck outside of room
Fixed: 2-way door not colliding
View Older Posts
